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Abstract 

Tasks and objects are two predominant ways of specifying distributed problems. A task is specified by 
an input/output relation, defining for each set of processes that may run concurrently, and each assignment of 
inputs to the processes in the set, the valid outputs of the processes. An object is specified by an automaton 
describing the outputs the object may produce when it is accessed sequentially. Thus, tasks explicitly state 
what may happen only when sets of processes run concurrently, while objects only specify what happens when 
processes access the object sequentially. Each one requires its own implementation notion, to tell when an 
execution satisfies the specification. For objects linearizability is commonly used, a very elegant and useful 
consistency condition. For tasks implementation notions are less explored. 

These two orthogonal approaches are central, the former in distributed computability, and the later in con¬ 
current programming, yet they have not been unified. Sequential specifications are very convenient, especially 
important is the locality property of linearizability, which states that one can build systems in a modular way, 
considering object implementations in isolation. However, many important distributed computing problems, 
including some well-known tasks, have no sequential specification. Also, tasks are one-shot problems with a 
semantics that is not fully understood (as we argue here), and with no clear locality property, while objects can 
be invoked in general several times by the same process. 

The paper introduces the notion of interval-sequential object. The corresponding implementation notion of 
interval-linearizability generalizes linearizability, and allows to associate states along the interval of execution 
of an operation. Interval-linearizability allows to specify any task, however, there are sequential one-shot objects 
that cannot be expressed as tasks, under the simplest interpretation of a task. It also shows that a natural 
extension of the notion of a task is expressive enough to specify any interval-sequential object. 

Thus, on the one hand, interval-sequential linearizability explains in more detail the semantics of a task, 
gives a more precise implementation notion, and brings a locality property to tasks. On the other hand, tasks 
provide a static specification for automata-based formalisms. 


Keywords: asynchronous system, concurrent object, distributed task, linearizability, object composability, se¬ 
quential specification. 


1 Introduction 


Concurrent objects and linearizability Distributed computer scientists excel at thinking concurrently, and 
building large distributed programs that work under difficult conditions with highly asynchronous processes that 
may fail. Yet, they evade thinking about concurrent problem specifications. A central paradigm is that of a shared 
object that processes may access concuiTently 1281142] |43, but the object is specified in ferms of a sequenfial 
specificafion, i.e., an aufomafon describing fhe oufpufs fhe objecf produces only when if is accessed sequenfially. 
Thus, a concuiTenf algorifhm seeks fo emulafe an allowed sequential behavior. 

There are various ways of defining whaf if means for an algorifhm fo implement an objecf, namely, fhaf if 
satisfies ifs sequenfial specification. One of fhe mosf popular consisfency conditions is linearizability ISTTl . (see 
surveys inigii). Given a sequential specification of an objecf, an algorifhm implements fhe objecf if every execu- 
fion can be fransformed fo a sequenfial one such fhaf (1) if respecfs fhe real-time order of invocafion and responses 
and (2) fhe sequenfial execution is recognized by fhe aufomafon specifying fhe objecf. If is fhen said fhaf fhe 
corresponding objecf implemenfafion is linearizable. Thus, an execution is linearizable if, for each operafion call, 
if is possible fo find a unique poinf in fhe interval of real-time defined by fhe invocafion and response of fhe oper¬ 
afion, and fhese linearization points induce a valid sequential execufion. Linearizabilify is very popular fo design 
componenfs of large systems because if is local, namely, one can consider linearizable objecf implemenfafions in 
isolafion and compose fhem wifhout sacrificing linearizabilify of fhe whole sysfem ifT^ . Also, linearizabilify is a 
non-blocking properfy, which means fhaf a pending invocafion (of a fofal operafion) is never required fo waif for 
anofher pending invocafion fo complete. Texfbooks such as |0128] |42j |43 include more defailed discussions of 
linearizabilify. 

Linearizabilify has various desirable properties, additionally fo being local and non-blocking: if allows falking 
abouf fhe state of an object, interactions among operations is captured by side-effects on object states; documen¬ 
tation size of an object is linear in the number of operations; new operations can be added without changing 
descriptions of old operations. However, as we argue here, linearizability is sometimes too restrictive. First, there 
are problems which have no sequential specifications (more on this below). Second, some problems are more natu¬ 
rally and succinctly defined in term of concurrenf behaviors. Third, as is well known, fhe specificafion of a problem 
should be as general as possible, fo allow maximum flexibilify fo bofh programmers and program executions. 

Distributed tasks Another predominant way of specifying a one-shot distributed problem, especially in dis¬ 
tributed computability, is through the notion of a task llTTl . Several tasks have been intensively studied in dis¬ 
tributed computability, leading to an understanding of their relative power ETll . to the design of simulations be¬ 
tween models l[8l, and to the development of a deep connection between distributed computing and topology E6\ . 
Formally, a task is specified by an input/output relation, defining for each set of processes that may run concur¬ 
rently, and each assignment of inputs to the processes in the set, the valid outputs of the processes. Implementation 
notions for tasks are less explored, and they are not as elegant as linearizability. In practice, task and implementa¬ 
tion are usually described operationally, somewhat informally. One of the versions widely used is that an algorithm 
implements a task if, in every execution where a set of processes participate (run to completion, and the other crash 
from the beginning), input and outputs satisfy the task specification. 

A main difference between tasks and objects is how they model the concurrency that naturally arises in dis¬ 
tributed systems: whiles tasks explicitly state what might happen for several (but no all) concurrency patterns, 
objects only specify what happens when processes access the object sequentially. 

It is remarkable that these two approaches have largely remained independent while the main distributed 
computing paradigm, consensus, is central to both. Neiger ll^ noticed this and proposed a generalization of 
linearizability called set-linearizability. He discussed that there are tasks, like immediate snapshot Q, with no 
natural specification as sequential objects. In this task there is a single operation lmmediate_snapshot(), such that 
a snapshot of the shared memory occurs immediately after a write. If one wants to model immediate snapshot as an 
object, the resulting object implements test-and-set, which is contradictory because there are read/write algorithms 
solving the immediate snapshot task and it is well-known that there are no read/write linearizable implementations 
of test-and-set. Thus, it is meaningless to ask if there is a linearizable implementation of immediate snapshot 
because there is no natural sequential specification of it. Therefore, Neiger proposed the notion of a set-sequential 
object, that allows a set of processes to access an object simultaneously. Then, one can define an immediate 
snapshot set-sequential object, and there are set-linearizables implementations. 

Contributions We propose the notion of an interval-sequential concurrent object, a framework in which an object 
is specified by an automaton that can express any concurrency pattern of overlapping invocations of operations, 

'Also both approaches were proposed the same year, 1987, and both are seminal to their respective research areas I30II37I . 
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that might occur in an execution (although one is not forced to describe all of them). The automaton is a direct 
generalization of the automaton of a sequential object, except that transitions are labeled with sets of invocations 
and responses, allowing operations to span several consecutive transitions. The corresponding implementation 
notion of interval-linearizability generalizes linearizability and set-linearizability, and allows to associate states 
along the interval of execution of an operation. While linearizing an execution requires finding linearization 
points, in interval-linearizability one needs to identify a linearization interval for each operation (the intervals 
might overlap). Remarkably, this general notion remains local and non-blocking. We show that most important 
tasks (including set agreement ifTTl ') have no specification neither as a sequential objects nor as a set-sequential 
objects, but they can be naturally expressed as interval-sequential objects. 

Establishing the relationship between tasks and (sequential, set-sequential and interval-sequential) automata- 
based specifications is subtle, because tasks admit several natural interpretations. Interval-linearizability is a frame¬ 
work that allows to specify any task, however, there are sequential one-shot objects that cannot be expressed as 
tasks, under the simplest interpretation of a task. Hence, interval-sequential objects have strictly more power to 
specify one-shot problems than tasks. However, a natural extension of the notion of a task has the same expressive 
power to specify one-shot concurrent problems, hence strictly more than sequential and set-sequential objects. See 
Figure [T] Interval-linearizability goes beyond unifying sequentially specified objecfs and fasks, it sheds new light 
on both of them. On the one hand, interval-sequential linearizability provides an explicit operational semantics to 
a task (whose semantics, as we argue here, is not well understood), gives a more precise implementation notion, 
and brings a locality property to tasks. On the other hand, tasks provide a static specification for automata-based 
formalisms such as sequential, set-sequential and interval-sequential objects. 

Related work Many consistency conditions have been pro¬ 
posed to define fhe correcf behavior of sequentially specified 
objecfs, fhaf guaranfee fhaf all fhe processes see fhe same 
sequence of operafions applied fo fhe objecf. Among fhe 
mosf nofable are atomicity 113411351 [36l . sequential consis¬ 
tency ||33l, and linearizability ll3T| . (See surveys iQAlldTI . and 
fexfbooks such as Q An exfension of lineariz- 

abilify suifed fo relativistic disfribufed systems is presenfed 
in 1221. Normality consisfency 1^ can be seen as an ex¬ 
fension of lineaiizabilify fo fhe case where an operation can 
involve more fhan one objecf. 

Neiger proposed unifying sequenfial objecfs and fasks, 
and defined sef-linearizabilify l3^ . In fhe aufomafon specifying a sef-sequenfial objecf, fransifions befween sfafes 
involve more fhan one operafion; fhese operafions are allowed fo occur concurrenfly and fheir resulfs can be 
concurrency-dependenf. Thus, linearizabilify corresponds fo fhe case when fhe fransifions always involve a single 
operafion. Lafer on if was again observered fhaf for some concurrenf objecfs if is impossible fo provide a se¬ 
quenfial specificalion, and similar nofion, buf based on histories, was proposed 1251 (no properties were proved). 
Transforming fhe question of wail-free read/wrile solvabilily of a one-shol sequential objecf, into fhe queslion of 
solvability of a fask was suggesled in ifT^ . The extension of fasks we propose here is reminiscenl to fhe conslruc- 
fion in Utl . 

Higher dimensional aulomala are used fo model execulion of concurrenf operafions, and are fhe mosf expressive 
model among olher common operafions lT9l . They can model fransifions which consisls of sefs of operations, and 
hence are relaled fo sef-linearizabilify, buf do nof nalurally model inferval-linearizabilify, and ofher concerns of 
concurrenf objecfs. There is work on partial order semantics of programs, including more flexible notions of 
linearizabilify, relaling fwo arbilrary sefs of histories lT5l . 

Roadmap The paper is composed of sections. If considers fhaf fhe basic definitions relaled to linearizabilify 
are known. Firsf, Seclion |2] uses a simple example fo illusfrafe fhe limifalions of bolh linearizabilify and sef- 
linearizabilify. Then, Seclion [3] infroduces fhe nofion of an inferval-sequenfial concurrenf objecf, which makes if 
possible fo specify fhe correcf concurrenf palferns, wilhouf reslricling fhem fo be sequenfial palterns. Seclion |4] 
defines inferval-linearizabilify and shows if is local and non-blocking. Then, Section |5] compares fhe ability of 
fasks and interval-sequential objecfs to specify one-shol problems. Finally, Seclion [^concludes fhe paper. 

^Weaker consistency conditions such as causal consistency (3), lazy release consistency ED, or eventual consistency Ezl are not 
addressed here. 
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Figure 1: Objecfs and consisfency conditions. The 
equivalence is befween refined fasks and one-shof 
interval-sequential objects. 
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2 Limitations of linearizability and set-linearizability 


Here we discuss in more detail limitations of sequential and set-sequential specifications (linearizability and set- 
linearizability). As a running example we use write-snapshot, a natural task that is implementable from read/write 
registers and has no natural specification as a sequential or set-sequential object. Many other tasks have the same 
problems. Appendix ICl presents other examples and additional details. 

2.1 The write-snapshot task 

Definition and implementation of write-snapshot Sometimes we work with objects with two operations, but 
that are intended to be used as one. For instance, a snapshot object U has operations write() (sometimes called 
update) and snapshot(). This object has a sequential specification and there are linearizable read/write algorithms 
implementing it (see, e.g., |0|28]|42j|43). But many times, a snapshot object is used in a canonical way, namely, 
each time a process invokes write(), immediately after it always invokes snapshot(). Indeed, one would like to 
think of such an object as providing a single operation, write_snapshot(), invoked with a value x to be deposited 
in the object, and when the operation returns, it gives back to the invoking process a snapshot of the contents of the 
object. It turns out that this write-snapshot object has neither a natural sequential nor a set-sequential specification. 
However, it can be specified as a fask and acfually is implemenfable from read/wrife regisfers. 

In fhe write-snapshot fask, each process pi sfarfs wifh a privafe inpuf Vi and oufpufs a sef seti safisfying fhe 
following: 

• Self-inclusion: {i, Vi) € seti. 

• Confainmenf: Vz, j : {seti C setj) V {setj C seti). 

Note fhaf fhe specification of wrife-snapshof is highly concurrenf: if only sfafes whaf processes mighf decide 
when fhey run until complefion, regardless of fhe specific inferleaving pattern of invocations and responses. A 
simple wrife-snapshof algorifhm based on read/wrife regisfers, is in Figure [2]below. 

The immediate snapshot fask Q is defined by adding an Immediacy requiremenf fo fhe Self-inclusion and 
Confainmenf requiremenfs of fhe wrife-snapshof fask. 

• Immediacy: V z, j : [{{j,Vj) G seti) A {{i,Vi) G setj)] {seti = setj). 

Figure[2]confains an algorifhm fhaf implemenfs wrife-snapshof (same idea of fhe well-known algorifhm of ifH). 
The infernal represenfafion of wrife-snapshof is made up of an array of single-wrifer mulfi-reader afomic regisfers 
MEM[l..n], initialized fo [_L, • • • , _L]. In fhe following, fo simplify fhe presenfafion we suppose fhaf fhe value 
written by pi is i, and fhe pair {i, Vi) is consequenfly denoted i. When a process pi invokes write_snapshot(z), if 
firsf wrifes ifs value i in MEM[i] flinelOTI). Then pi issues repealed classical “double collecls” unfil if obfains fwo 
successive read of fhe full array MEM, which provide if wifh fhe same sef of non-± values flines I02ll05]) . When 
such a successful double colled occurs, pi refurns fhe confenf of ifs Iasi read of fhe array MEM flinelOhb. Lei us 
recall fhaf fhe reading of fhe n array enfries are done asynchronously and in an arbifrary order. In Appendix |Bl if 
is shown fhaf fhis algorifhm implemenfs fhe wrife-snapshof fask. 


operation write_snapshot(i) is % issued by pi 
(01) MEM[i] ^ i; 

(02) newi <— Ui<j<n{MEM[j] such that MEM[j] ^ _L}; 

(03) repeat oldi •<— newp, 

(04) newi ■<— such that MEM[j] ^ _L} 

(05) until {oldi = newi) end repeat; 

( 06 ) return(newi). 


Figure 2: A write-snapshot algorithm 

Can the write-snapshot task be specified as a sequential object? Suppose there is a deterministic sequential 
specification of write-snapshot. Since the write-snapshot task is implementable from read/write registers, one 
expects that there is a linearizable algorithm A implementing the write-snapshot task from read/write registers. 
But A is linearizable, hence any of its executions can be seen as if all invocations occurred one after the other, 
in some order. Thus, always there is a first invocation, which must output the set containing only its input value. 
Clearly, using A as a building block, one can trivially solve test-and-set. This conttadicts the fact that test-and-set 
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cannot be implemented from read/write registers. The contradiction comes from the fact that, in a deterministic 
sequential specification of write-snapshot, the values in the output set of a process can only contain input values of 
operations that happened before. Such a specification is actually modelling a proper subset of all possible relations 
between inputs and outputs, of the distributed problem we wanted to model at first. This phenomenon is more 
evident when we consider the execution in Figure [3l which can be produced by the write-snapshot algorithm in 
Figure |2] in the Appendix. 
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Figure 3: A linearizable write-snapshot execution that predicts the future 

Consider a non-deterministic sequential specification of write-snapshot (the automaton is in Appendix |B]|. 
When linearizing the execution in Figure [3l one has to put either the invocation of p or q first, in either case the 
resulting sequential execution seems to say that the first process predicted the future and knew that q will invoke the 
task. The linearization points in the figure describe a possible sequential ordering of operafions. These anomalous 
fulure-predicling sequenfial specificalions resulf in linearizations poinfs wifhouf fhe intended meaning of “as if fhe 
operation was atomically executed af fhaf poinf.” 
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Figure 4: A wrife-snapshof execufion fhaf is nof sef-linearizable 

Why set-linearizability is not enough Neiger noted fhe problems wifh fhe execufion in Figure[3]discussed above, 
in fhe confexf of fhe immediate snapshof fask. He proposed in |[^ fhe idea fhaf a specificafion should allow fo 
express fhaf sefs of operafions fhaf can be concurrenf. He called fhis notion set-linearizability. In sef-linearizabilify, 
an execution accepted by a set-sequential automaton is a sequence of non-empfy sefs wifh operafions, and each 
sef denofes operafions fhaf are execufed concurrenfly. In fhis way, in fhe execufion in Figure |3l fhe operafions of p 
and q would be sef-lineaiized fogelher, and fhen fhe operafion of r would be sef-linearized alone af fhe end. While 
sef-linearizabilify is sufficienf fo model fhe immediafe-snapshof fask, if is nof enough for specifying mosf ofher 
fasks. 

Consider fhe wrife-snapshof fask. In sef-linearizabilify, in fhe execufion in Figured (which can be produced by 
fhe wrife-snapshof algorifhm, buf is nof a legal immediafe snapshof execufion), one has fo decide if fhe operafion 
of q goes fogefher wifh fhe one of p or r. In eifher case, in fhe resulfing execufion a process seems fo predicf a 
fufure operafion. In fhis case fhe problem is fhaf fhere are operations fhaf are affecfed by several operafions fhaf 
are nof concurrenf (in Figure HI q is affecfed by bofh p and r, whose operafions are nof concurrenf). This cannof be 
expressed as a sef-sequenfial execufion. Hence, fo succincfly express fhis fype of behavior, we need a more flexible 
framework in which if is possible fo express fhaf an operafion happens in an inferval of time fhaf can be affecfed 
by several operations. 

2.2 Additional examples of tasks with no sequential specification and a potential solution 

As we shall see, most tasks are problematic for dealing with them thr'ough linearizability, and have no deterministic 
sequential specifications. Some have been studied in the past, such as the following, discussed in more detail in 
Appendix 1C.II 
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• adopt-commit ini is a one-shot shared-memory object useful to implement round-based protocols for set- 
agreement and consensus. Given an input u to the object, the result is an output of the form {commit, v) 
or {adopt, v), where commit/adopt is a decision that indicates whether the process should decide value v 
immediately or adopt it as its preferred value in later rounds of the protocol. 

• conflict detection lU has been shown to be equivalent to the adopt-commit. Roughly, if at least two different 
values are proposed concurrently at least one process outputs true. 

• safe-consensus 121, a weakening of consensus, where the agreement condition of consensus is retained, but 
the validity condition becomes: if the first process to invoke it returns before any other process invokes it, 
then it outputs its input; otherwise the consensus output can be arbitrary, not even the input of any process. 

• immediate snapshot Q, which plays an important role in distributed computability |l5l|71|45l. A process can 
write a value to the shared memory using this operation, and gets back a snapshot of the shared memory, 
such that the snapshot occurs immediately after the write. 

• k-set agreement im, where processes agree on at most k of their input values. 

• Exchanger ll25l . is a Java object that serves as a synchronization point at which thr'eads can pair up and 
atomically swap elements. 

Splitting an operation in two To deal with these problematic tasks, one is tempted to separate an operation 
into two operations, set and get. The first communicates the input value of a process, while the second produces 
an output value to a process. For instance, fe-set agreement is easily transformed into an object with a sequential 
specification, simply by accessing it through set to deposit a value into the object and get that returns one of the 
values in the object. In fact, every task can be represented as a sequential object by splitting the operation of the 
task in two operations (proof in Appendix IC.2I) . 

Separating an operation into a proposal operation and a returning operation has several problems. First, the 
program is forced to produce two operations, and wait for two responses. There is a consequent loss of clarity in 
the code of the program, in addition to a loss in performance, incurred by a two-round trip delay. Also, the intended 
meaning of linearization points is lost; an operation is now linearized at two linearization points. Furthermore, the 
resulting object may provably not be the same; a phenomenon that has been observed several times in the context 
of iterated models (e.g., in l[T2ll20ll40l l is that the power of the object can be increased, if one is allowed to invoke 
another object in between the two operations. Further discussion of this issue is in Appendix 1C. 2 1 

3 Concurrent Objects 

This section defines fhe notion of an intervai-sequentiai concurrenf objecf, which allows to specify behaviors of 
all the valid concurrent operation patterns. These objects include as special cases sequential and set-sequential 
objects. To this end, the section also describes the underlying computation model. 

3.1 System model 

The system consists of n asynchronous sequential processes, P = {pi, ... ,p„}, which communicate through a 
set of concurrent objects, OBS. Each consistency condition specifies the behaviour of an object differently, for 
now we only need to define its interface, which is common to all conditions. The presentation follows 1191 13111^ . 

Given a set OP of operations offered by the objects of the system to the processes P, let Inv be the set of all 
invocations to operations that can be issued by a process in a system, and Res be the set of all responses to the 
invocations in Inv. There are functions 


id : Inv —>■ P 
op : Inv OP 

op : Res OP (1) 

res : Res Inv 
obj : OP OBS 


where id{in) tells which process invoked in € Inv, op{in) tells which operation was invoked, op{r) tells which 
operation was responded, res{r) tells which invocation corresponds to r G Res, and obj{oper) indicates the 
object that offers operation oper . There is an induced function id : Res —> P defined by id{r) = id{res{r)). 
Also, induced functions obj : Inv OBS defined by obj {in) = obj{op{in)), and obj : Res —> OBS defined 
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by obj{r) = obj{op{r)). The set of operations of an object X, OP{X), consists of all operations oper, with 
obj{oper) = X. Similarly, Inv{X) and Res{X) are resp. the set of invocations and responses of X. 

A process is a deterministic automaton that interacts with the objects in OBS. It produces a sequence 
of steps, where a step is an invocation of an object’s operation, or reacting to an object’s response (includ¬ 
ing local processing). Consider the set of all operations OP of objects in OBS, and all the corresponding 
possible invocations Inv and responses Res. A process p is an automaton r), with states S and func¬ 
tions z/, r that describe the interaction of the process with the objects. Often there is also a set of initial states 
So C S. Intuitively, if p is in state cr and z/(cr) = {op,X) then in its next step p will apply operation op 
to object X. Based on its current state, X will return a response r to p and will enter a new state, in accor¬ 
dance to its transition relation. Finally, p will enter state r(cr, r) as a result of the response it received from X. 

Finally, a system consists of a set of processes, P, a set of objects OBS so 
that each p ^ P uses a subset of OBS, together with an initial state for each 
of the objects. 

A configuration is a tuple consisting of the state of each process and each 
object, and a configuration is initial if each process and each object is in an 
initial state. An execution of the system is modelled by a sequence of events 
H arranged in a total order H = {H,<h ), where each event is an invocation 
in G Inv or a response r G Res, that can be produced following the process 
automata, interacting with the objects. Namely, an execution starts, given any initial configuration, by having any 
process invoke an operation, according to its transition relation. In general, once a configuration is reached, the 
next event can be a response from an object to an operation of a process or an invocation of an operation by a 
process whose last invocation has been responded. Thus, an execution is well-formed, in the sense that it consists 
of an interleaving of invocations and responses to operations, where a processes invokes an operation only when 
its last invocation has been responded. 

3.2 The notion of an Interval-sequential object 

To generalize the usual notion of a sequential object e.g. ||9j[3ll (recalled in Appendix lAl). instead of considering 
sequences of invocations and responses, we consider sequences of sets of invocations and responses. An invoking 
concurrency class C C 2^'^'", is a non-empty subset of Inv such that C contains at most one invocation by the 
same process. A responding concurrency class C, C P 2^®^, is defined similarly. 

Interval-sequential execution An interval-sequential execution h is an alfernafing sequence of invoking and 
responding concurrency classes, sfarfing in an invoking class, h = Iq, Ro,Ii,Ri ,... , Im, Rm, where fhe following 
condifions are satisfied 

1. For each R G h, any fwo invocations mi, m 2 G R are by differenf processes, id{ini) ^ id{in 2 ). Similarly, 
for Ri G /i if ri, r 2 G Ri fhen id{ri) ^ id{r 2 ), 

2. Lef r € Ri for some Ri G h. Then fhere is in G Ij for some j < i, such fhaf res{r) = in and furthermore, 
fhere is no ofher in' wifh id{in) = id{in') wifh in' G Ij/, j < j' < i. 

If follows fhaf an execution h consisfs of mafching invocafions and responses, perhaps wifh some pending invoca- 
fions wifh no response. 

Interval-sequential object An interval-sequential objecf X is a (nof necessarily finite) Mealy slate machine 
(Q, (5) whose oulpuf values R are responding concurrency classes Rof X, R P are 

determined bolh by ifs currenl slate s & Q and fhe currenl inpuf I G where I is an invoking concurrency 

class of X. There is a sel of initial states Qq of X, Qo P Q- The Iransilion relalion 5 P Qx x x Q 

specifies bolh, fhe oulpuf of fhe aufomafon and ifs nexf sfale. If X is in slate q and if receives as inpuf a sel of 
invocafions I, fhen, if {R, q') G 5{q, I), fhe meaning is fhaf X may relurn fhe non-empfy sel of responses R and 
move lo sfale q'. We slress fhaf always bolh I and R are non-empfy sefs. 

Interval-sequential execution of an object Consider an inilial slate go C Qo oi X and a sequence of inpuls 
Iq,Ii, ... Im- Then a sequence of oulpuls fhaf X may produce is Rq, Ri, ... Rm, where (i?j, qj+i) G 6{qi,R). 
Then fhe interval-sequential execution of X sfarfing in q^ is qQ,lQ,RQ,qi,Ii,Ri,... ,qm,Im, Rm- However, we 
require fhaf fhe objecl’s response af a sfale uniquely determines fhe new slate, i.e. we assume if 5{q, R) conlains 
{Ri,qi+i) and {Ri, q'ij^i) then qj+i = Then we may denote the interval-sequential execution of X, starting 
in go by /i = Iq, Ro,Ii, Ri,..., Im, Rm, because the sequence of states qo, qi,... ,qm is uniquely determined by 
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qo, and by the sequences of inputs and responses. When we omit mentioning go we assume there is some initial 
state in Qo that can produce h. 

Notice that X may be non-deterministic, in a given state qi with input li it may move to more than one state 
and return more than one response. Also, sometimes it is convenient to require that the object is total, meaning 
that, for every singleton set I G 2^”'^ and every state q in which the invocation inv in I is not pending, there is an 
{R, q') G 5{q, I) in which there is a response to inv in R. 

Our definition of interval-sequential execution is motivated by the fact that we are interested in well-formed 
executions h = Iq,Rq,Ii,Ri, ... ,Im,Rm- Informally, the processes should behave well, in the sense that a 
process does not invoke a new operation before its last invocation received a response. Also, the object should 
behave well, in the sense that it should not return a response to an operation that is not pending. 

The interval-sequential specification of X, ISSpec{X), is the set of all its interval-sequential executions. 


Representation of interval-sequential executions In general, we will be thinking of an interval-sequential 
execution h as an alternating sequence of invoking and responding concurrency classes starting with an invoking 
class, h = Iq, Rq, Ii, Ri, ..., Im, Rm- However, it is sometimes convenient to think of an execution as a a 


on a subset S C CC{X), where CC{X), is the set with all invoking and responding 
S ^ S r s ^ S Sr s 


total order S = {S,- 

concurrency classes of X; namely, h = Iq Rq R 
In addition, the execution h = Iq, Rq, R, Ri,..., Im, R 


Rl ^ ^ dm ^ Rm- 

can be represented by a table, with a column for 
each element in the sequence h, and a row for each process. A member in G Ij invoked by pk (resp. a response 
r G Rj to pk) is placed in the k’th row, at the 2j-th column (resp. 2j -|- 1-th column). Thus, a transition of the 
automaton will correspond to two consecutive columns, Ij,Rj- See Figure |5J and several more examples in the 
figures below. 

Inferval-sequential objecfs include as particular cases set-sequential and sequential objects, as illustrated in 
Figure [T] 


Remark 1 (Sequential and Set-sequential objects). Let X be an interval-sequential object, (Q, , 6). 

Suppose for all states q and all I, if 5{q, I) = {R, q'), then |ii| = |/|, and additionally each r ^ Ris a response 
to one in G /. Then X is a set-sequential object. If in addition, |/| = \R\ = 1, then X is a sequential object in the 
usual sense. 


3.3 Examples: Validity and validity with abort 

Consider an object X with a single operation validity(x), that can be invoked by each process, with a proposed 
input parameter x, and a very simple specification: an operation returns a value that has been proposed. This prob¬ 
lem is easily specified as a fask, see Appendix ID. 21 Indeed, many fasks include this property, such as consensus, 
set-agreement, etc. As an interval-sequential object, it is formally specified by an automaton, where each state 
q is labeled with two values, q.vals is the set of values that have been proposed so far, and q.pend is the set of 
processes with pending invocations. The initial state qo has qQ.vals = 0 and qQ.pend = 0. If in is an invocation 
to the object, let val{in) be the proposed value, and if r is a response from the object, let val{r) be the responded 
value. For a set of invocations I (resp. responses R) vals{I) denotes the proposed values in I (resp. vals{R)). 
The transition relation 6{q, I) contains all pairs (i?, q') such that: 

• Ifr G R then id{r) G q.pend or there is an in G / with id{in) = id{r), 

• If r G i? then val{r) G q.vals or there is an in G / with val{in) = val{r), and 

• q'.vals = q.val U vals{I) and q'.pend = {q.pend U ids{I)) \ ids{R). 

On the right of Figure |5]there is part of a validity object automaton. On the left of Figure|5]is illustrated an interval- 
sequential execution with the vertical red double-dot lines: Iq, Rq, Ii,Ri, where Iq = {p.validity(l), q.validity(2)}, 
Rq = {p.resp(2)}, R = {r.validity(3)}, Ri = {q.s/resp(3), r.resp(l)}. 

The interval-linearizability consistency notion described in Section |4] will formally define how a general ex¬ 
ecution (blue double-arrows in the figure) can be represented by an interval-sequential execution (red double-dot 
lines), and hence tell if it satisfies the validity object specification. Notice that the execution in Figure [5] shows that 
the validity object has no specification neither as a sequential nor as a set-sequential object, for reasons similar to 
those discussed in Section ITT] about Figure ID 

Augmenting the validity object with an abort() operation As an illustration of the expressiveness of an interval- 
sequential automaton, let us add an operation denoted abort() to the validity object, to design a validity k-abort 
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validity(l) 

resp{2) 

validity(2) 







Figure 5: An execution of a validity object, and the corresponding part of an interval-sequential automata 
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1 - ( 

jborted 

1 -> -> 


Figure 6: An execution of a Validity-Abort object (1) 


object. Since the validity object is not set-linearizable, neither is the validity with abort object. Intuitively, a 
process can invoke abort() to “block” the object, but this might happen only if there are at least k concurrent abort 
operations. The operation abort() returns either aborted or not Aborted, to indicate its result. If all the concurrent 
abort() operations return aborted, then any operation happening together or after them, returns aborted as well. 
Hence, if only one process invokes abort() then the object behaves as a Validity object. How do we formally 
argue that the execution in Figure |^is correct? Interval-Linearizability is a correctness implementation notion that 
serves this purpose, defined next. In Appendix 1C.31 the validity object is formally defined. 

4 Interval-Linearizability 

We first define interval-linearizability and then prove it is local and non-blocking. 

4.1 The notion of interval-linearizability 

Interval-sequential execution of the system Consider a subset S C CC of the concurrency classes of the 

objects OBS in the system and an interval-sequential execution S = {S, —?>), defining an alternating sequence of 
invoking and responding concurrency classes, starting with an invoking class. For an object X, the projection of 

5 at X, S'lx = {Sx, is defined as follows: (1) for every C G 5 with at least one invocation or response on 
X, Sx contains a concurrency class C', consisting of the (non-empty) subset of C of all invocations or responses 

of X, and (2) for every C, C" € Sx,C' C" if and only if there are T', T" G S such that C C T', C" C T" 
and T' T". 

We say that S = {S, —>) is an interval-sequential execution of the system if 5|x is an interval-sequential 
execution of X for every X G OBS. That is, if 5|x G ISSpec{X), the interval-sequential specification of X, 
for every X G OBS. Let S = {S, —>) be an interval-sequential execution. For a process p, the projection of S 
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at p, 5|p = {Sp, is defined as follows: (1) for every C £ S with an invocation or response by p, Sp contains 
contains a class C with the invocation or response by p (there is at most one event by p in C), and (2) for every 

a,b £ Sp, a b if and only if there are T', T" £ S such that a £T',b £ T" and T' T". 


Interval-linearizability Recall that an execution of the system is a sequence of invocations and responses (Sec¬ 
tion Kn . An invocation in an execution E is pending if it has no matching response, otherwise it is complete. An 
extension of an execution E is obtained by appending zero or more responses to pending invocations. 

An operation call in £' is a pair consisting of an invocation and its matching response. Let comp{E) be the 
sequence obtained from E by removing its pending invocations. The order in which invocation and responses in E 
happened, induces the following partial order: OP = {OP, -^) where OP is the set with all operation calls in E, 
and for each pair opj^, op 2 £ OP, opj^ op 2 if and only if term{opi) < init{op 2 ) in E, namely, the response 
of opi appears before the invocation of op 2 - Given two operation opi and op 2 , opi precedes op 2 if opj^ —op 2 , 
and they are concurrent it op^ ^ op 2 and op 2 opj^. 

Consider an execution of the system E and its associated paitial order OP = {OP, -^), and let S = {S, -^) 
be an interval-sequential execution. We say that an operation a £ OP appears in a concurrency class S' £ S if its 


invocation or response is in S'. Abusing notation, we write a £ S'. We say that respects also written as 
if for every a,b £ OP such that a b, for every T', T" £ S with a £ T' and b £ T", it holds that 


Definition 1 (Interval-linearizability). An execution E is interval-linearizable if there is an extension E of E and 
an interval-sequential execution S = {S, —>) such that 

1. for every process p, comp{E)\p = S\p, 

2. for every object X, Six £ ISS{X) and 

3. respects where OP = {OP, -^) is the partial order associated to comp{E). 

We say that S = {S, —>) is an interval-linearization of E. 


Remark 2 (Linearizability and set-linearizability). When we restrict to interval-sequential executions in which 
for every invocation there is a response to it in the very next concurrency class, then interval-linearizability boils 
down to set-linearizability. If in addition we demand that every concurrency class contains only one element, then 
we have linearizability. See Figure\J} 

We can now complete the example of the validity object. In Figure |7] there is an interval linearization of the 
execution in Figure [5l Similarly, for the validity with abort object, in Figure [8] there is an interval linearization of 
the execution in Figure!^ 
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Figure 7: An execution of a Validity object 
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Figure 8: An execution of a Validity-Abort object (2) 
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write_snapshot(l) —>■ {1,4} 
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p write_snapshot(l) I resp(l,4) 
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s write_snapshot(4) 




write snapshot(2) 

resp(l, 2,4) 






r write_snapshot(3) resp(l, 2,3,4) 
s res2?(l, 2, 3,4) 


Figure 9: An execution of the write-snapshot task. 

4.2 An interval-sequential implementation 

Once we have formally defined the notion of interval-linearizability, we can show that the write-snapshot algorithm 
in Section l2d1 is interval-linearizable. 

The write-snapshot interval-sequential object Here is a formal definition of this task, using an interval- 
sequential object based on the validity object of Section 1331 The write-snapshot object X has a single operation 
write_snapshot(x) that can be invoked by each process, with a proposed input parameter x, and returns a set. In 
the interval-sequential automata each state q is labeled with two values, q.vals is the set of id-values that have been 
proposed so far, and q.pend is the set of processes with pending invocations. The initial state q^ has qQ.vals = 0 
and qo-pend = 0. If in is an invocation to the object, let val{in) be the proposed value, and {id{in),val{in) be 
the proposed id-value pair. If r is a response from the object, let val{r) be the responded id-value pair. For a set of 
invocations I (resp. responses R) vals{I) denotes the proposed id-value pairs in I (resp. vals{R)). The transition 
relation 5{q, I) contains all pairs {R, q') such that: 

• If r S i? then id{r) € q.pend or there is win £ I with id{in) = id{r), 

• Ifr € R then val{r) = q.val U vals{I) 

• q'.vals = q.val U vaLs{I) and q'.pend = {q.pend U ids{I)) \ ids{R). 

An example of an execution an the transitions through the automata is in Figured 

The write-snapshot algorithm is interval-linearizable The specification of a write-snapshot object contains 
every interval-sequential execution satisfying the self-containment and containment properties (Appendix |B] con¬ 
tains a correctness proof in the usual style, without interval-linearizability), thus, to show that an execution of 
the algorithm is interval-linearizable, we need to transform it into a interval-sequential execution that satisfy the 
real-time order of invocations and responses. 

As with linearizability, interval-linearizability specifies a safety property, it is not about liveness. Thus, before 
showing that the algorithm of Figure |2] is interval-linearizable, we recall the usual termination arguments for this 
style of snapshot algorithm. The invocation of write_snapshot() by any process pi terminates, because, as the 
number of processes is fixed (equal fo n), and a process invokes write_snapshot() at most once, it follows that a 
process can execute at most (n — 1) double collects where each time it sees new values. 

Theorem 1. Tlw write-snapshot algorithm of Figure^is interval-linearizable. 

Proof The proof is very similar to the usual linearizability proof for the obstruction-free implementation of a snap¬ 
shot object (we follow Il42l (Sect. 8.2.1)), except that now two points have to be identified, one for the invocation 
of an operation and one for the response. 

Consider any execution E and let pi be any process that terminates. As it returns a value seti (line l06l) . we 
have seti = oldi = newi where newi corresponds to the last asynchronous read of MEM[l..n] by pi, and oldi 
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corresponds to the previous asynchronous read of MEM[l..n]. Let T[oldi] the time at which terminates the read 
of MEM[l..n] returning oldi, and T[newi] the time at which starts the read of MEM[l..n] returning newi. As 
oldi = newi, it follows that there is a time r,, such that T[oldi] < Ti < T[newi] and, due to the termination 
predicate of line|05] the set of non-_L values of MEM[l..n] at time Ti is equal to seti. 

For any process pi that terminates with seti, we pick a time r* as described above. Let f = < Tx 2 < 

■ ■ ■ < Txm be the ordered sequence of chosen times, assuming the number of processes that terminate is m 
{m < n). Clearly if Ti = Tj, then seti = setj, but it is possible that seti = setj, with r* < tj, in case 
there is no write in between Tj and Tj. Thus, for each longest subsequence of times in r with the same set 
seti, we pick as representative, the first time in the subsequence, and consider the following subsequence f' 
of r, where p (1 < p < m) is the number of different sets returned by the processes. The subsequence is 
f' = Tx'^ < < ■ ■ ■ < Tx'^, where the sets , setx>^ ,■■■, setx>^ are all different. 

For each subindex x' in f', consider the set that is output sef^/. Let be the set of processes in the execution 
that output setx'.. Using these sets and the sequence of times above, we define an interval-sequential execution 

s 

as follows. The interval-sequential execution S = {S, —>) consists of an alternating sequence of invoking and 
responding concurrency classes. The first invoking concurrency class Ii has all invocations of processes in set^/^, 
then Ri, the responding concurrency class with all responses by processes in followed by I 2 , the con currency 
class with all invocations in \ and the responding class with all responses by processes in and so 
on. For an example, see the interval sequential execution in the right of Figure 0in Appendix iBl 

If there are pending invocation in S we just add a responding class in which there is a response to each of them 
and they output all values written in the execution. Observe that S respects the real-time order of the invocations 
and responses of E because if the response of p* precedes the invocation of pj then seti cannot contain pj and 
then Ti < Tj, which implies that the invocation of pj in S happens after the invocation of pj. Thus, the algorithm 
is interval-linearizable. 

^Theorem\T\ 


4.3 Interval-linearizability is composable and non-blocking 

Even though interval-linearizability is much more general than linearizability it retains some of its benefits. Proofs 
are in Appendix 10 

Theorem 2 (Locality of interval-linearizability). An execution E is interval-linearizable if and only if E\x is 
interval-linearizable, for every object X. 

Proof We prove that if each E\x is interval-linearizable for every X, then E is interval-linearizable (the other 
direction is trivial). Consider an interval-linearization S'|x = {Sx,—^) of E\x ■ Let Rx be the responses 
appended to Ex to get ,S|jv and let E be the extension of E obtained by appending the responses in the sets Rx 
in some order. Let OP = {OP, -^) be the partial order associated to comp{E). 

We define the following relation S = {S, —)•). The set S is the union of all Sx, namely, the union of all 

5 

concurrency classes in the linearizations of all objects. The relation —is defined as follows: 

1. For every objecf X, 

2. For every pair of distinct objects X and Y, for every a € OP\x and b € OP\y such that a b and a € S' 

g 

and b G S", for a responding class S' G S and an invoking class S" G S, we define S' —> S". 

S 

Claim 1. The relation —> is acyclic. 

S "S S 

Although —is acyclic, it might not be transitive. Consider the transitive closure —^ of —)■. One can easily 

show that —is acyclic, hence it is a partial order over S. It is well-known that a partial order can be extended 

S* "s ^ 

to a total order. Let S* = {S, —a total order obtained from —)•. It could be that in S* concurrency classes 

do not alternate between invoking and responding, however, the first concuiTency class certainly is an invoking 
one. To get an interval-sequential execution, we merge consecutive invoking classes and responding classes in S* 

(namely, we take the union of such a sequence) and adjust —>) accordingly. Let T* = (T, — >) be the resulting 
interval-sequential execution. We claim that T* is an interval-sequential linearization of E. 
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Figure 10: An execution that does not satisfy the validity task. 

By the definition of 5 = {S, —>) above, we have that for every object X, T*\x S ISS{X). From the 
assumption that each 5|jis: respects the real time order in comp{E\x), and by the definition of S, it follows that 
—)• respects the real time order in comp{E), namely, —> respects —That and the definition of S' = (S, —)■) 
also imply that for every process p, comp{E) \p = T*, This completes the proof of the lemma. □ 

When we consider the specification ISS{X) of and interval-sequential object with total operation opName, 
for every S € ISS{X) and every invocation {inv{opName)} to opName, the interval-sequential execution 
S ■ {inv{opName)} ■ S' belongs to ISS{X), for some responding concuiTency class containing a matching 
response to {inv{opName)}. 

Theorem 3. Let E be an interval-linearizable execution in which there is a pending invocation inv{op) of a total 
operation. Then, there is a response res {op) such that E ■ res {op) is interval-linearizable. 

5 Tasks and their relationship with automata-based specifications 

A task is a static way of specifying a one-shot concuiTent problem, namely, a problem with one operation that can 
be invoked once by each process. Here we study the relationship between this static way of defining a problem, 
and fhe aufomafa-based ways of specifying a problem fhaf we have been considering. Proofs and addifional defails 
are in Appendix 10 

Roughly, a fask {I, O, A) consisfs of a sef of inpuf assignmenfs I, and a sef of oufpuf assignmenfs O, which 
are defined in ferms of sefs called simplexes of fhe form s = {(idi, xi),..., (id^, x^)}. A singleton simplex is 
a vertex. A simplex s is used fo denofe fhe inpuf values, or oufpuf values in an execufion, where Xi denofes fhe 
value of fhe process wifh idenfify idj, eifher an inpuf value, or an oufpuf value. Bofh Z and O are complexes, which 
means fhey are closed under confainmenf. There is an inpuf/oulpuf relation A, specifying for each inpuf simplex 
s G X, a subcomplex of O consisting of a sef of oufpuf simplexes A(s) C O fhaf may be produced wifh input s. If 
s, s' are two simplexes in Z with s' C s, then A(s') C A(s). Formal definitions are in Appendix iDl 

When does an execution satisfy a task? A task is usually specified informally, in fhe sfyle of Section lA2l E.g., 
for fhe A:-sef agreemenf fask one would say fhaf each process proposes a value, and decides a value, such fhaf 
(validify) a decided value has been proposed, and (agreemenf) af most k different values are decided. A formal 
definition of when an execution satisfies a fask is derived nexf. A fask T has only one operation, task(), which 
process id* may call wifh value Xi, if (id*, Xi) is a vertex of Z. The operation task(xj) may refurn pi fo fhe process, 
if (idjjj/j) is a vertex of O. Let E be an execution where each process calls task() once. Then, ue denotes the 
simplex containing all input vertices in E, namely, if in E there is an invocation of task(xj) by process idj then 
(id* ,Xi) is in Us. Similarly, te denotes the simplex containing all output vertices in E, namely, (id*, y*) is in te 
iff there is a response pi to a process id* in E. We say that E satisfies task T = {I, O, A) if for every prefix E' 
of E, if holds fhat te' G A{aE')- It is necessary fo consider all prefixes of an execufion, fo prevenf anomalous 
execufions fhaf globally seem correcf, buf in a prefix a process predicfs fufure invocations, as in fhe execufion of 
fhe validity fask in Figure [Tol^ 

^This prefix requirement has been implicitly considered in the past by stating that an algorithm solves a task if any of its executions 
agree with the specification of the task. 
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Figure 11: Two special output simplexes ai,a 2 , and interval-linearizations of two executions with corresponding 
outputs 


From tasks to interval-sequential objects A task is a very compact way of specifying a distributed problem that 
is capable of describing allowed behaviours for certain concurrency patterns, and indeed it is hard to understand 
what exactly is the problem being specified. The following theorem (with its proof) provides an automata-based 
representation of a task, explaining which outputs may be produced in each execution, as permitted by A. 

Theorem 4. For every task T, there is an interval-sequential object Ot such that an execution E satisfies T if and 
only if it is interval-linearizable with respect to Ot- 

To give an intuition of the insights in the proofs of this theorem, consider the immediate snapshot task (Fig¬ 
ure [T^ . A simple case is the output simplex <74 in the center of the output complex, where the three processes 
output {p, q, r}. It is simple, because this simplex does not intersect the boundary. Thus, it can be produced as 
output only when all three operations are concurrent. More interesting is output simplex 173 , where they also may 
run concurrently, but in addition, the same outputs may be returned in a fully sequential execution, because <73 
intersects both the 0 -dimensional and the 1 -dimensional boundary of the output complex. In fact <73 can also be 
produced if p, q are concurrent, and later comes r, because 2 vertices of <73 are in A(p, q). Now, consider the two 
more awkward output simplexes ai,a 2 in A(i 7 ) added to the immediate-snapshot output complex in Figure [TT] 
where ai = {(p, {p, q}), {q, {p, q, r}), (r, {p, r})}, and ^2 = {(p, {p, q, r}), {q, {q}), (r, {r})}. At the bottom of 
the figure, two executions and their interval-linearizations are shown, though there are more executions that are 
interval-linearizable and can produce cri and 172 . Consider < 72 , which is in A((7). Simplex 172 has a face, {q}, in 
A{q), and another face, {r} in A(r). This specifies a different behavior from the output simplex in the center, 
than does not intersect with the boundary. Since A({( 7 }) = {< 7 }, it is OK for q to return {q} when it invokes and 
returns before the others invoke. Now, since {{p, q, r}, q, r} G A({p, q, r}) then it is OK for r to return {r} after 
everybody has invoked. Similarly, since {{p, q, r}, q, r} G A({p, q, r}), p can return {{p, q, r}, q, r}. The main 
observation here is that the structure of the mapping A encodes the interval-sequential executions that can produce 
the outputs in a given output simplex. In the example, A precludes the possibility that in a sequential execution 
the processes outputs the values in ai, since A specifies no process can decide without seeing anyone else. 

From one-shot interval-sequential objects to tasks The converse of Theorem |4] is not true. Lemma [T] shows 
that even some sequential objects, such as queues, cannot be represented as a task. Also, recall that there are tasks 
with no set-sequential specification. Thus, both tasks and set-sequential objects are interval-sequential objects, but 
they are incomparable. 
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Lemma 1. There is a sequential one-shot object O such that there is no task Tq, satisfying that an execution E is 
linearizable with respect to O if and only if E satisfies Tq (for every E). 

We have stablished that tasks have strictly less expresive power than interval-sequential one-shot objects, how¬ 
ever, a slight modification of the notion of tasks allows to equate the power of both approaches for specifying 
distributed one-shot problems. Roughly speaking, tasks cannot model interval-sequential objects because they do 
not have a mechanism to encode the state of an object. The extension we propose below allows to model states. 

In a refined task T = {I, O, A), I is defined as usual and each output vertex of O has the form {idi.yi, a'f) 
where idi and y* are, as usual, the ID of a process and an output value, and a[ is an input simplex called 
the set-view of idi. The properties of A are maintained and in addition it satisifies the following: for ev¬ 
ery a £ Z, for every (idi,yi,a'f) € A(cr), it holds that a[ C a. An execution E satisfies a refined task 
T if for every prefix E' of E, it holds that A{aE>) contains the simplex {{idi,yi,aiE") '■ {idi,yi) € te' A 
E" (which defines cxiE") is the shortest prefix of E' containing the response [idi, yi)}. 

We stress that, for each input simplex a, for each output vertex (idi,yi,ai) € A(cr), ai is a way to model 
distinct output vertexes in A(cj) whose output values (in {idi,yi)) are the same, then a process that outputs that 
vertex does not actually output Uj. In fact, the set-view of a process idi corresponds to the set of invocations 
that precede the response {idi,yi) to its invocation in a given execution (intuitively, the invocations that a process 
“sees” while computing its output value ). Set-views are the tool to encode the state of an object. Also observe that 
if E satisfies a refined fask T, then the set-views behave like snapshots: 1) a process itself (formally, its invocation) 
appears in its set-view and 2) all set-view are ordered by containment (since we assume E is well-formed). 

As already mentioned, interval-sequential objects and refined tasks have the same ability to specify distributed 
one-shot problems, as the following theorems show. The proof of Theorem 0 is essentially the same as the proof 
of Theorem m 

Theorem 5. For every one-shot interval-sequential object O with a single total operation, there is a refined task 
Tq such that any execution E is interval-linearizable with respect to O if and only if E satisfies Tq- 

Theorem 6. For every refined task T, there is an interval-sequential object Ot such that an execution E satisfies 
T if and only if it is interval-linearizable with respect to Ot- 

6 Conclusion 

We have proposed the notion of an interval-sequential object, specified by a state machine similar to the ones used 
for sequentially specified objecfs, except that transitions are labeled with sets of invocations and responses, instead 
of operations, to represent operations that span several consecutive transitions. Thus, in a state an invocation 
might be pending. The corresponding consistency condition is interval-linearizability. If an execution is interval- 
linearizable for an object X, its invocations and responses can be organized, respecting real-time, in a way that they 
can be executed through the automaton of X. Thus, contrary to the the case of linearizability where to linearize an 
execution one has to find unique linearization points, for interval-linearizability one needs to identify an interval 
of time for each operation, and the intervals might overlap. We have shown that by going from linearizability to 
interval-linearizability one does not sacrifice the properties of being local and non-blocking. 

We have discovered that interval-sequential objects have strictly more expressive power than tasks. Any algo¬ 
rithm that solves a given task is interval-linearizable with respect to the interval-sequential object that corresponds 
to the task, however, there are one-shot objects that cannot be expresses as tasks. We introduced the notion of 
refined tasks and prove that interval-sequential objects and refined tasks are just two different styles, equally ex¬ 
pressive, of specifying concurrent one-shot problems, the first operational, and the second static. This brings 
benefits from each style to the other, and finally provides a common framework to think about linearizability, 
set-linearizability, interval-linearizability, and tasks. 

There are various directions interesting to pursue further. In the domain of concurrent specifications, there is 
interest in comparing the expressive power of several models of concurrency, e.g. |[T9l . and as far as we know, 
no model similar to ours has been considered. Higher dimensional automata Il39l . the most expressive model 
in II3, seems related to set-linearizability. Also, several papers explore partial order semantics of programs. More 
flexible notions of linearizability, relating two arbitrary sets of histories appear in ifTSl . but without stating a com- 
positionality result, and without an automata-based formalism. However it is worth exploring this direction further, 
as it establishes that linearizability implies observational refinement, which usually entails compositionality (see, 
e.g., E^ l. Also, it would be interesting to consider that in this semantics two events in a single trace can be related 
in three ways: definitely dependent, definitely concurrent or unrelated. 


14 


Several versions of non-determinism were explored in ifTOl . which could be understood through the notions in 
this paper. Also, it would be interesting to consider multi-shot task versions that correspond to interval-sequential 
objects, as well as the implications of the locality property. 

As observed in f2M . devising linearizable objects can be very difficult, requiring complex algorithms to work 
correctly under general circumstances, and often resulting in bad average-case behavior. Programmers thus opti¬ 
mize algorithms to handle common scenarios more efficiently. The authors propose speculative linearizability to 
simplify the design of efficient yet robust linearizable protocols. It would be interesting to see if similar techniques 
can be used for interval-specifications of concurrent objects proposed here, and if our more generic composability 
proof sheds light on the composability result of flM . 

Often concurrent data structures shared require linear worst case time to perform a single instance of an oper¬ 
ation in any non-blocking implementation ifldl . else, they are not linearizable e.g. ll29l . Thus, concurrent specifi¬ 
cations, such as interval-linearizable objects open possibilities of sub-linear time implementations. 

Finally, Shavit ll44]l summarizes beautifully the common knowledge state that “it is infinitely easier and more 
intuitive for us humans to specify how abstract data structures behave in a sequential setting. Thus, the standard 
approach to arguing the safety properties of a concurrent data structure is to specify the structure’s properties 
sequentially, and find a way fo map its concurrent executions to these ‘correct’ sequential ones.” We hope interval- 
linearizability opens the possibility of facilitating reasoning about concurrent specifications, when no sequential 
specifications are appropriate. 
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A Linearizability 


A sequential object O is a (not necessarily finite) Mealy state machine (Q, Inv, Res, 6) whose output values are 
determined both by its current state s € Q and the current input I € Inv. If O is in state q and it receives as input 
an invocation in G Inv by process p, then, if 5{q, inv) = (r, q'), the meaning is that O may return the response r 
to the invocation inv by process p, and move to state q'. Notice that the response r has to be to the invocation by 
p, but there may be several possible responses (if the object is non-deterministic). Also, it is convenient to require 
that the object is total, meaning that for any state q, 6{q, I) ^ 0, for all I G Inv. 

Considering any object defined by a sequenfial specification on total operations, linearizability lISTTl general¬ 
izes the notion of an atomic read/write object formalized in Il34l [36]l . and encountered in virtual memory-based 
distributed systems 1351. 

Intuitively, an execution is linearizable if it could have been produced by multiplexing the processes on a single 
processor. This definition considers complete histories. If the execution is partial, an associated complete execution 
can be defined as follows. The local execution II\i of each process pi for which the last operation is pending (i.e., pi 
issued an invocation and there no matching response event), is completed with a response matching the invocation 
event. Thus, it may be possible to associate different complete histories with a given partial execution. 

An execution E is linearizable if there is and extension E of E and a sequential execution S such that: 

• comp{E) and S are equivalent (no process can distinguish between comp{E) and S). 

• S' is legal (the specification of each object is respected). 

• The total order S respects the partial order OP associated to comp{E) (any two operations ordered in OP 
are ordered the same way in S). 

As shown in ISH, the linearizability consistency condition has the “composability” property (called “local¬ 
ity” in llsn i. which states that a computation E is linearizable if and only if, for each of its objects X, E^X is 
linearizable. 


B Additional details about the write-snapshot task 

Recall that in the write-snapshot task the write() and snapshot() operations are merged to define a single operation 
denoted write_snapshot(). It satisfies the self-inclusion and containment properties. Notice that the immediate 
snapshot task [Tl which motivated Neiger to propose set-linearizability is a write-snapshot which additionally 
satisfies the following immediacy property: V : [((j, —)seti) A {{i, —)setj)] {seti = setj). 

For completeness and comparison, we inlcude the following proof in the usual, somewhat informal style, of 
the correctness of the write-snapshot algorithm. To simplify the presentation we suppose that the value written by 
Pi is i, and the pair {i, Vi) is consequently denoted i. 

Theorem 7. The algorithm of Figure^wait-free implements write-snapshot. 

Proof Let us first show that the invocation of write_snapshot() by any process pi terminates. As there is a bounded 
number of processes, and a process invokes write_snapshot() at most once, it follows that a process can be forced 
to execute at most (n — 1) double collects, and the termination follows. 

The self-inclusion property follows immediately from line lOH and the fact that no value is ever withdrawn 
from the array MEM. 

To prove the containment property, let us consider two processes pi and pj, which return seti and setj, re¬ 
spectively. Let us first consider pi. As it returns seti, we have seti = oldi = newi where newi corresponds 
to the last asynchronous read of MEM[l..n] by pi, and oldi corresponds to the previous asynchronous read of 
MEM[l..n]. Let T[oldi] the time at which terminates the read of MEM[l..n] returning oldi, and T[newi\ the time 
at which starts the read of MEM[l..n] returning newi. As oldi = newi, it follows that there is a time r^, such that 
T[oldi] < Ti < T[newi] and, due to the termination predicate of line|05l the set of non-_L values of MEM[l..n] at 
time Ti is equal to seti. 

The same applies to pj, and there is consequently a time Tj at which the set of non-_L values of MEM[l..n] 
is equal to setj. Finally, as (1) r* < Tj or r* > and (b) values written in MEM[l..n] are never withdrawn, it 
follows that we necessarily have seti C setj or setj C seti. ^Theorem^ 


hi 


A finite state automaton describing the behavior of a write-snapshot object The non-deterministic automaton 
of Figure [12] describes in an abbreviated form all the possible behaviors of a write-snapshot object in a system 
of three processes p, q, and r. To simplify the figure, it is assumed that a process pi proposes i. Each edge 
correspond to an invocation of write_snapshot(), and the list of integers L labeling a transition edge means that the 
corresponding invocation of write_snapshot() is by one of the processes pi such that i £ L. The value returned by 
the object is {L}. Thus, for the linearization of the execution in Figure |3l the path in the automaton goes thr'ough 
states 0, {1,2}, {1,2}, {1,2,3}. 

Any path starting from the initial empty state, and in which a process index appears at most once, defines an 
execution of the write-snapshot task that does not predict the future. Moreover if, when it executes, a process 
proceeds from the automaton state si to the state S 2 , the state S 2 defines the tuple of values output by its invocation 
of write_snapshot(). 



Figure 12: A non-deterministic automaton for a write-snapshot object 


C Additional discussion and examples of linearizability limitations 

C.l Additional examples of tasks with no sequential specification 

Several tasks have been identified that are problematic for dealing with them through linearizability. The problem 
is that they do not have a natural sequential specification. One may consider linearizable implementations of 
restricted sequential specifications, where if two operations occur concurrently, one is linearized before the other. 
Thus, in every execution, always there is a first operation. In all cases we discuss below, such an implementation 
would provably be of a more powerful object. 

An adopt-commit object ifTTll is a one-shot shared-memory object useful to implement round-based protocols 
for set-agreement and consensus. It supports a single operation, adopt_commit(). The result of this operation is 
an output of the form {commit, v) or {adopt, v), where the second component is a value from this set and the 1st 
component indicates whether the process should decide value v immediately or adopt it as its preferred value in 
later rounds of the protocol. It has been shown to be equivalent to the conflict detection object IH, which supports 
a single operation, check(). It returns true or false, and has the following two properties: In any execution that 
contains a check('(;) operation and a check('(;') operation with v ^ v', at least one of these operations returns true. 
In any execution in which all check operations have the same input value, they all return false. As observed in ||3l 
neither adopt-commit objects nor conflict detectors have sequential specification. A deterministic linearizable 
implementation of an adopt-commit object gives rise to a deterministic implementation of consensus, which does 
not exist. Similarly, the first check operation linearized in any execution of a conflict detector must return false and 
subsequent check operations with different inputs must return true, which can be used to implement test-and-set, 
for which no deterministic implementation from registers exists. 

In the safe-consensus problem of ||2l, the agreement condition of consensus is retained, but the validity con¬ 
dition is weakened as follows: if the first process to invoke it returns before any other process invokes it, then it 
outputs its input; otherwise the consensus output can be arbitrary, not even the input of any process. There is no 
sequential specification of this problem, because in any sequential specification, the first process to be linearized 
would obtain its own proposed value. See Appendix 1C.31 
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Two examples that motivated Neiger are the following ll^ . In the immediate snapshot task 171, there is a 
single operation lmmediate_snapshot(), such that a snapshot occurs immediately after a read. Such executions 
play an important role in distributed computability ll5l|71|45l. There is no sequential specification of this task. One 
may consider linearizable implementations of restricted immediate snapshot behavior, where if two operations 
occur concurrently, one is linearized before the other, and where the first operation does not return the value by the 
second. But such an implementation would provably be of a more powerful object (immediate snapshots can be 
implemented wait-free using only read/write registers), that could simulate test-and-set. 

The other prominent example exhibited in |[38l is the k-set agreement task ifTTIl . where processes agree on at 
most k of their input values. Any linearizable implementation restricts the behavior of the specification, because 
some process final value would have fo be ifs own inpuf value. This would be an arlifacf imposed by linearizabilify. 
Moreover, fhere are implemenfations of sef agreemenf wifh executions where no process chooses its own initial 
value. 


C.2 Splitting operations to model concurrency 

One is tempted to separate an operation into two, an invocation and a response, to specify the effect of concur¬ 
rent invocations. Consider two operations of an object, op^() and op 2 (), such that each one is invoked with a 
parameter and can return a value. Suppose we want to specify how the object behaves when both are invoked 
concurrently. We can separate each one into two operations, inv_opj() and resp_opj(). When a process wants to 
invoke opj(3:), instead it first invokes inv_opj(x), and once the operation terminates, it invokes resp_opj(), to get 
back the output parameter. Then a sequential specification can define whaf fhe operation refurns when fhe hisfory 
is inv_opi(xi), inv_op 2 (x 2 ), resp_opi(), resp_op 2 (). 

/c-Sef agreemenf is easily Iransformed info an objecf wifh a sequenfial specificalion, simply by accessing if 
fhrough fwo differenf operations, one that deposits a value into the object and another that returns one of the values 
in the object. Using a non-deterministic specification that remembers which values the object has received so far, 
and which ones have so far been returned, one captures the behavior that at most k values are returned, and any of 
the proposed values can be returned. This trick can be used in any task. 

Separating an operation into a proposal operation and a returning operation has several problems. First, the 
program is forced to produce two operations, and wait for two responses. There is a consequent loss of clarity in 
the code of the program, in addition to a loss in performance, incurred by a two-round trip delay. Also, the intended 
meaning of linearization points is lost; an operation is now linearized at two linearization points. Furthermore, the 
resulting object may provably not be the same. A phenomenon that has been observed several times (see, e.g., 
in lfT2l l20l l40ll l is that the power of the object can be increased, if one is allowed to invoke another object in 
between the two operations. Consider a test-and-set object that returns either 0 or 1, and the write-snapshot object. 
It is possible to solve consensus among 2 processes with only one snapshot object and one test-and-set object 
only if it is allowed to invoke test-and-set in between the write and the snapshot operation. Similarly, consider a 
safe-consensus object instead of the test-and-set object. If one is allowed to invoke in between the two operations 
of write-snapshot a safe-consensus object, then one can solve consensus more efficiently IfTTIl . 

The object corresponding to a task with two operations Let T be a task (X, O, A). We will model T as a 
sequential object Ot in which each process can invoke two operations, set and get, in that order. The idea is that 
set communicates to Ot the input value of a process, while get produces an output value to a process. Thus, the 
unique operation of T is modelled with two operations. The resulting sequential object is non-deterministic. 

We define Ot- The sef of invocafions and responses are fhe following: 

Inv{OT) = {set{pi,ini) \ {pi,ini) € X} U {get(pj) |pj € 11} 

Res{OT) = {set{pi,ini) : OK \ {pi,ini) G X} U {get(pj) : ouU |pj G If A {pi,outi) G O} 

The set of states of Ot is Q = {{a,T)\a G X A r G A((t)}. Intuitively, a set (cr, r) represents that the inputs 
and output Ot knows at that state are a and r. The initial state of is (0,0). We define 6 as follows. Let (cr, r) and 
{a', t') be two states of Ot- Then, 

• If r = r', a ^ a' and a' = {a U (pi, mj)} G X, then 5{{a, r), set(pi, irii)) contains the tuple (set(pj, irii) : 
OK, 

• If a = a', T ^ t' and r' = {r U {pi,outi)} G A(cr), then (5((cj, r), get(pj)) contains the tuple (get(pj) : 
outi, (cr',r')). 

Note that for every sequential execution S of Ot-, it holds that G A(cj^), where is the input simplex 
containing every input vertex in S and, similarly, is the output simplex containing every output simplex in S. 
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validity(l) —>■ 2 abort() —>• notAborted 



Figure 13: An execution of a Validity-Abort object (3) 

C.3 Validity and Safe-consensus objects 

We first discuss the validity object with abort, and then the safe-consensus object. 

C.3.1 Validity with abort object 

An interval-sequential object can be enriched with an abort operation that takes effect only if a given number 
of processes request an abort concurrently. Here we describe the example of Section 13.31 in more detail, that 
extends the validity object with an abort operation that should be invoked concurrently by at least k processes. 
As soon as at least k processes concurrently invoke abort the object will return from then on aborted to every 
operation. Whenever less than k processes are concurrently invoking abort, the object may return NotAborted to 
any pending abort. An example appeared in Figure [6l for k = 2. Another example is in Figure [131 where it is 
shown that even though there are two concurrent abort operations, they do not take effect because they are not 
observed concurrently by the object. This illustrates why this paper is only about safety properties, the concepts 
here cannot enforce liveness. There is no way of guaranteeing that the object will abort even in an execution where 
all processes issue abort at the same time, because the operations may be executed sequentially. 

The k-validity-abort object is formally specified as an inferval-sequenfial objecf by an aufomafon, fhaf can 
be invoked by eifher propose(t!) or abort, and it responds with either resp(n) or aborted or NotAborted. Each 
state q is labeled with three values: q.vals is the set of values that have been proposed so far, q.pend is the set of 
processes with pending invocations, and q.aborts is the set of processes with pending abort. The initial state qo 
has qo.vals = 0, qo-pend = 0 and qo.aborts = 0. If in is an invocation to the object different from abort, let 
val{in) be the proposed value, and if r is a response from the object, let val{r) be the responded value. 

For a set of invocations I (resp. responses R) vals{I) denotes the proposed values in I (resp. vals{R)). Also, 
aborts{I) denotes the set of processes issuing an req Abort in I, and notAborted{R) is the set of processes getting 
notAborted in R. 

The transition relation 6{q, I) contains all pairs (i?, q') such that: 

1 . Ifr € R then id{r) G q.pend or there is an in G I with id{in) = id{r), 

2. If (r = resp(n) G i? or notAborted G R) then aborted ^ R, 

3. If r = resp(?;) G R then val{r) = v € q.vals or there is an in G / with val{in) = val{r), 

4. If notAborted G R, then 0 < \q.aborts\ -|- \aborts{I)\ < k 

5. If \q.aborts\ + \aborts{I)\ > k then aborted G R. 

6 . q'.vals = q.val U vals{I), q'.pend = {q.pend U ids{I)) \ ids{R), and 
q.aborts = {q.aborts U aborts{I)) \ notAborted{R) 

C.3.2 Safe-consensus 

Recall that the safe-consensus problem of ||2l, is similar to consensus. The agreement condition of consensus is 
retained, but the validity condition is weakened as follows: if the first process to invoke it returns before any other 
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Figure 14: Part of an interval-sequential automaton of safe-consensus 


process invokes it, then it outputs its input; otherwise the consensus output can be arbitrary, not even the input of 
any process. As noticed in Section ICTl there is no sequential specification of this problem. 

See Figure [14] for part of the automata corresponding to safe-consensus, and examples of interval executions 
in Figure [13] 
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Figure 15: Examples of interval-executions for safe-consensus 


D Tasks 

D.l Basic definitions 

A task is the basic distributed equivalent of a function, defined by a sef of inpufs fo fhe processes and for each 
(disfribufed) inpuf fo fhe processes, a sef of legal (disfribufed) oufpufs of fhe processes, e.g., Ii26l . In an algorifhm 
designed fo solve a fask, each process sfaits wifh a privafe inpuf value and has fo evenfually decide iiTevocably 
on an oufpuf value. A process pi is inifially nol aware of fhe inpufs of ofher processes. Consider an execution 
where only a subsef of k processes parficipafe; fhe ofhers crash wifhouf faking any sfeps. A sef of pairs s = 
{(idi, xi),..., (idfc, Xfc)} is used fo denofe fhe inpuf values, or oufpuf values, in fhe execution, where Xi denofes 
fhe value of fhe process wifh idenfify idj, eifher an inpuf value, or a oufpuf value. 

A sef s as above is called a simplex, and if fhe values are inpuf values, if is an input simplex, if fhey are oufpuf 
values, if is an output simplex. The elemenfs of s are called vertices. An input vertex v = (idj, represenfs fhe 
initial slate of process idj, while an output vertex represenfs ifs decision. The dimension of a simplex s is |s| — 1, 
and if is full if if conlains n verfices, one for each process. A subsef of a simplex is called a. face. Since any number 
of processes may crash, simplexes of all dimensions are of inferesf, for faking info accounl execufions where only 
processes in fhe simplex participate. Therefore, fhe sef of possible inpuf simplexes forms a complex because ifs 
sefs are closed under confainmenf. Similarly, fhe sef of possible oufpuf simplexes also form a complex. 

More generally, a complex /C is a sef of vertices V{IC), and a family of finite, nonempty subsels of V{K), 
called simplexes, salisfying: (1) ifv^V {1C) fhen {u} is a simplex, and (2) if s is a simplex, so is every nonempty 
subsef of s. The dimension of K. is fhe largesf dimension of ifs simplexes, and /C is pure of dimension k if every 
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Figure 16: Immediate snapshot task 



Figure 17: Part of the write-snapshot output complex 


simplex belongs to a /c-dimensional simplex. In distributed computing, the simplexes (and complexes) are often 
chromatic, since each vertex r; of a simplex is labeled with a distinct process identity. 

Definition 2 (Task). A task T for n processes is a triple (I, O, A) where X and O are pure chromatic (n — 1)- 
dimensional complexes, and A maps each simplex s from I to a subcomplex A(s) ofO, satisfying: 

1. A(s) is pure of dimension s 

2. For every t in A(s) of dimension s, ID(f) = ID(s) 

3. If s, s' are two simplexes in X with s' C s then A(s') C A(s). 

We say that A is a carrier map from the input complex X to the output complex O. 

A task is a very compact way of specifying a distributed problem, and indeed it is hard to understand what 
exactly is the problem being specified. Intuitively, A specifies, for every simplex s e X, the valid outputs A(s) 
for the processes in ID(s) assuming they run to completion, and the other processes crash initially, and do not take 
any steps. 

The immediate snapshot task is depicted in Figure [T^ On the left, the input simplex is depicted and, on the 
right, the output complex appears. 

In figure [it] one simplex s is added to the output complex of the immediate snapshot task of Figure [T6l where 
■s = {(P) {Pj q})^ (?) {P) 7) ^})) (^) {P) 7) ^})}- This simplex s corresponds to the execution of FigurelH 

D.2 Validity as a task 

Recall the validity object is specified as an interval-sequential object in Section [331 which is neither linearizable 
nor set-linearizable. In the usual, informal style of specifying a task, the definition would be very simple: an 
operation returns a value that has been proposed. A bit more formally, in an execution where a set of processes 
participate with inputs I (each x G I is proposed by at least one process), each participating process decides a 
value in I. To illustrate why this informal style can be misleading, consider the execution in Figure [TOl where the 
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three processes propose values I = {1, 2, 3}, so according to the informal description it should be ok that they 
decide values {1, 2, 3}. However, for the detailed interleaving of the figure, it is not possible that p and q would 
have produced outputs that they have not yet seen. 

To define validity formally as a task, the following notation will be useful. It defines a complex that repre¬ 
sents all possible assignments of (not necessarily distinct) values from a set U to the processes. In particular, all 
processes can get the same value x, for any x G (7. Given any finite set U and any integer n > 1, we denote 
by complex{U, n) the (n — 1)-dimensional pseudosphere E6\ complex induced by U: for each i G [n] and each 
X G (7, there is a vertex labeled (i, x) in the vertex set of complex{U, n). Moreover, u = {(idi, tti),..., (id^, u^)} 
is a simplex of complex{U, n) if and only if u is properly colored with identities, that is idj ^ idj for every 
1 < i < j < k. \n particular, compiex({ 0 ,1}, n) is (topologically equivalent) to the (n — 1)-dimensional sphere. 
For u G complex{U, n), we denote by val{u) the set formed of all the values in U corresponding to the processes 
in u. Similarly, for any set of processes P, complex{U, P) is the |P — 1|-dimensional pseudosphere where each 
vertex is labeled with a process in P, and gets a value from U. 

The validity task over a set of values U that can be proposed, is (X, O, A), where Z = O = complex{U, n). 
The carrier map A is defined as follows. For each simplex s ^Z, A(s) = complex{U', P'), where P' is fhe sef of 
processes appearing in s and U' is fheir proposed values. 


E Proofs 

Claim [1] The relation 


is acyclic. 




Proof For fhe sake of confradicfion, suppose fhaf —> is nof acyclic, namely, fhere is a cycle C = Si 

S S Sx 

... —)• Sm-i —^ Sm , wifh Si = Sm- We will show fhaf fhe exisfence of C implies fhaf is nof acyclic, for 

some objecf X, which is a confradicfion fo our initial assumpfions. 

Firsf nofe fhaf if cannof be fhaf each Si is a concurrency class of fhe same objecf X, because if so fhen C is 

a cycle of which confradicfs fhaf is a fotal order. Thus, in C fhere are concurrency classes of several 
objects. 

In what follows, by slight abuse of notation, we will write S' 

g 

the second case in the definition of —>. 

Note that in C there is no sequence Si 


op 


S2 


^ S" if S' and S” are related in S because of 

077 077 

Ss because in S whenever T' —^ T", we have that T' is 


a responding class and T" is an invoking class, by definition. Thus, in C there must be a sequence Si 


op 


S2 


Sx, 


... St St+i St+ 2 - Observe that in S, we have S 2 St since is transitive, hence the sequence 

can be shortened: Si S 2 St St+i St+ 2 - Note that Si and St are responding classes while S 2 
and St+i are invoking classes. 

Now, since Si S 2 , there are operations o, 6 G OP such that a b, a € Si and b G S 2 - Similarly, for 

op op 

St —^ St+i, there are c, d G OP such that c —^ d, c ^ St and d G St+i- This implies that term{a) < init{b) 
and term{c) < init{d). Observe that if we show a —^ d then, by definition of S, we have Si —^ if Si and 


St+i are concurrent classes of distinct objects, and Si 

St 


Sy, 


St+i otherwise. Hence, the sequence Si 


op, 


St+i St +2 can be shortened to Si 


^ St+i ^ St +2 or ^ St+i ^ St+ 2 . Repeating this 


enough times, in the end we get that there are concurrency classes Si, Sj in C such that Si 

Sx 

is a contradiction since —^ is acyclic, by hypothesis. 

To complete the proof of the claim, we need to show that a 


Sx, 


Si 


Sx, 


Si, which 


op 


d, i.e., term{a) < init{d). We have four 


cases: 


1 . if 6 = c, then term{a) < init{b) < term{b) = term{c) < init{d), hence a d. 

op op 

2. If b —^ c, then term{a) < init{b) < term{b) < init{c) < term{c) < init{d), hence a —^ d. 


3. Ifc 


op 


_ g^ 

b, then we have that St S 2 , because each S'jx = {Sx, 


respects the real time order in 


_ g g 

coTnp{E\x), by hypothesis. But we also have that S 2 St, which contradicts that is a total order. 
Thus this case cannot happen. 

op op 

4. If b and c are concurrent, i.e., b ^ c and c ^ b, then note that if init{d) < term{a), then term{c) < 


init{d) < term{a) < init{b), which implies that c 
follows that term{a) < init{d). 


op 


b and hence b and c are not concurrent, fro which 
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Theorem [3] Let E be an interval-linearizable execution in which there is a pending invocation inv{op) of a total 
operation. Then, there is a response res{op) such that E ■ res{op) is interval-linearizable. 

Proof Since E is interval-linearizable, there is an interval-linearization S € ISS{X) of it. If inv{op) appears 
in S, we are done, because S contains only completed operations and actually it is an interval-linearization of 
E ■ res{op), where res{op) is the response to inv{op) in S. 

Otherwise, since the operation is total, there is a responding concurrency class S' such that S ■ {inv{op)} ■ S' G 
ISS{X), which is an interval-linearization of E ■ res{op), where res{op) is the response in S' matching inv{op). 

^Tfeeoremldl 


function sequences {E) is 

i <r- 1; e •<— first event in F •<— empty execution 
(To, To •(— 0; T (To; B •<— tq; 
while B B do 

if (e is an invocation) 
then if (n \ Ti_i = 0 ) 

then (7i •<— CTi U {e} 

else (7i+i <— aiU {e}; Ti+i •(— n; 

A ^— T • (Tj; B ^— B ' 'ri\ i, ^i -j- 1 

end if 

else Ti •<— Ti U {e} 

end if; 

B •(— B • e; e •(— next event to e in B 

end while; 

A ^ A - ai; B ^ B ■ n; return {A, B). 


Figure 18: Producing a sequence of faces of the invocation simplex a and response simplex r of an execution E. 

For the rest of the section we will often use the following notation. Let E be an execution. Then, ue and te 
denote the sets containing all invocations and responses of E, respectively. 

Claim 2. For every execution E, the function sequences() in Fi sure \\^Droduces sequences A = (Tq, ■ ■ ■, <7^ and 
B = To,... ,Tm such that 
L k = m. 

2. £7o = 0 C fJi C . . . C fJm-1 C am = CTE and Tq = 0 C n C . . . C r^-l ^Tm = Te- 

3. If E has no pending invocations, then Tm-i C Tm, otherwise Tm-i = Tm 

4. If E satisfies a task with carrier map A, then, that for each i, Ti G A((Tj). 

5. For every response e and invocation F in E such that e precedes e' and they do not match each other, we 
have i < j, where i is the smallest integer such that e G b and j is the smallest integer such that e' G cry 

6. For every response e of E in Ti \ B-i, Ui contains all invocations preceding e in E. 

Proof Items (1), (2) and (6) follow directly from the code. For item (3), note that if E has no pending invocations, 
it necessarily ends with a response, which is added to Tm, and thus Tm-i C Tm- For item (4), consider a pair Ui 
and Ti, and let E' be the shortest prefix of E that contains each response in r*. Note that the simplex containing all 
invocations in E' is crj. Since, by hypothesis, E satisfy T, it follows that b G A(crj). 

For item (5), consider such events e and e'. Since e precedes e', the procedures analyzes first e, from which 
follows that it is necessarily true that i < j, so we just need to prove that i j. Suppose, by contradiction, that 
i = j. Consider the beginning of the while loop when e' is analyzed. Note that e' ^ ai at that moment. Also, note 
that e ^ Ti \ rj_i because i is the smallest integer such that e G b and its was analyzed before e'. Thus, when the 
procedure process e', puts it in Uj+i, which is a contradiction, because in the final sequence of simplexes e' ^ ai. 

^Claim^2\ 

Theorem |4] For every fask T, fhere is an inferval-sequenfial objecf Ot such fhaf any execution E salisfies T if 
and only if if is inferval-linearizable wifh respecf fo Ot- 


X 



Proof The structure of the proof is the following. (1) First, we define Ot using T, (2) then, we show that every 
execution that satisfies T, is interval-linearizable with respect to Ot, and (3) finally, we prove that every execution 
that is interval-linearizable with respect to Ot, satisfies T. 

Defining Ot- Lef T = (X, O, A). To define Ot, we firsf define ifs sefs wifh invocations, response and sfafes: 
Inv = {{id, x) : {{id, x)} G X }, Res = {{id, y) : {{id, y)} GO} and Q = {(cr, r) : a G I At G O}. The 
inferval-sequenfial objecf Ot has one inifial sfafe: (0,0). Then Ot will have only one operation and so fhe name 
of if does nof appear in fhe invocation and responses. 

The fransifion function S is defined as follows. Consider an inpuf simplex a of T and lef E be an execufion 
fhaf satisfies T wifh aE = cr and te G /S.{(Te)- Consider fhe sequences (Tq = 0 C ui C . . . C Um = cte and 
tq = ^ C Ti C ... C Tm = te thaf Sequences in Figure [18] produces on E. Then, for every i = 1,... ,m, 
6{{ai-i,Ti-i),ai \ confains {{(Ti,Ti),Ti \ Tj-i). In ofher words, we use fhe sequences of faces fo define an 
inferval-sequenfial execufion (informally, a grid) fhaf will be accepfed by Ot'. the execution has 2m concurrency 
classes, and for each i = 1 ,..., m, the invocation {pj, —) (of process pj) belongs to the 2i — 1-th concurrency 
class if {pj,—) G Ui \ <Tj_i, and the response to the invocation of appears in the 2i-th concurrency class if 
{pj, —) G Ti\ Ti-i. We repeat the previos construction for every such a and E. 

If E satisfies T, it is interval-linearizable: Consider an execution E that satisfies T. We prove fhaf E is 
interval-linearizable with respect to Ot. Since E satisfies T, we have fhaf te G A((Te). By definition, A((t) is 
dim(fj)-dimensional pure, fhen fhere is a dim((T)-dimensional 7 G A((t) such fhaf te is a face of 7 . Lef E be an 
exfension of E in which fhe responses in 7 \rE are added in some order. Thus, fhere are no pending operation in E. 
Consider fhe sequences of simplexes produced by Sequences in Figure [T 8 ]on E. As we did when defined Ot, 
fhe fwo sequence define an inferval-sequenfial execufion S. We have fhe following: (1) S is an inferval-sequenfial 
execufion of Ot, by consfrucfion, (2) for every p, 5|p = E\p, by consfrucfion, and (3) Claim |2|5 implies fhaf S 
respecf fhe real-fime order of invocafions and responses in E: if opi —^ op 2 in fhe partial order OP = {OP, — 
associafed fo E, fhen, by fhe claim, fhe response of opi appears for fhe firsf time fhe sequence in r* and fhe 
invocafion of op 2 appears for fhe firsf in fhe sequence in aj, wifh i < j, and hence, by construction, opi precedes 
op 2 in S. We conclude that S is an interval-linearization of E. 

If E is interval-linearizable, it satisfies T: Consider an execution E that is interval-linearizable with respect to 
Ot. We will show that E satisfies T. There is an inferval-sequenfial execufion S fhaf is a linearization of E, since 
E is inferval-linearizable. Consider any prefix E' of E and lef S' be fhe shorfesf prefix of S such fhaf (1) if is an 
inferval-sequenfial execufion and (2) every complefed invocafion in E' is complefed in S' (note that there might 
be pending invocations in E' that does not appear in S'). By construction. S' defines fwo sequences of simplexes 
(To = 0 C (Ti C ... C (Tm and tq = 0 C n C ... C wifh r* € A((Tj), for every i = 1, ... ,m. Observe fhaf 
cte' = Cm and te' X Tm, and fhus te' G /S.{(7e') because G /S.{am)- Whaf we have proved holds for every 
prefix E' of E, fhen we conclude fhaf E safisfies T. ^Theorem]^ 

Lemma [ 1 ] There is a sequenfial one-shof objecf O such fhaf fhere is no fask Tq, safisfying fhaf an execufion E is 
linearizable wifh respecf fo O if and only if E safisfies Tq (for every E). 

Proof Consider a resfricfed queue O for fhree processes, p, q and r, in which, in every execufion, p and q invoke 
eng(l) and enq{2), respectively, and r invokes deq{). If fhe queue is empfy, r’s dequeue operation gefs X. 

Suppose, for fhe sake of confradicfion, fhaf fhere is a corresponding fask Tq = (X, O, A), as required by 
fhe lemma. The inpuf complex X consisfs of one vertex for each possible operation by a process, namely, fhe 
sef of vertices is {{p,enq{l)),{q,enq{2)),{r,deq{))}, and X consisfs of all subsefs of fhis set Similarly, fhe 
oufpuf complex O confains one verfex for every possible response fo a process, so if consisfs of fhe sef of vertices 
{{p, ok), {q, ok), {r, 1), {r, 2), (r, X)}. If should confain a simplex ax = {{p, ok), {q, ok), {r, x)} for each value of 
X G {1, 2, X}, because fhere are executions where p, q, r get such values, respectively. See Figure [19] 

Now, consider the three sequential executions of the figure, ai, a 2 and a±. In ai fhe process execute their 
operations in the order p, q, r, while in 02 the order is q,p, r. In ai the response to r is 1, and if a 2 it is 2. Given 
that these executions are linearizable for O, they should be valid for Tq. This means that every prefix of ai should 
be valid: 


{{p,ok)} = A{{p,enq{l)) 

{{p, ok), {q, ok)} G A{{{p, enq{l), {q, enq{2)}) 
cci = {{p, ok), {q, ok), {r, 1)} G A{{{p, enq{l), {q, enq{2), {r, deq{))}) = A{a) 


XI 


p 

ai q 
r 
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Figure 19: Counterexample for a simple queue object 


Similarly from 02 we get that 

^^2 = {{p, ok), {q, ok), (r, 2 )} € A{a) 

But now consider as, with the same sequential order p, q, r of operations, but now r gets back value 2. This 
execution is not linearizable for O, but is accepted by Tq because each of the prefixes of as is valid. More 
precisely, the set of inputs and the set of outputs of 02 are identical to the sets of inputs and set of outputs of as- 

^ Lemma fn 

Theorem m For every one-shot interval-sequential object O with a single total operation, there is a refined fask 
To such fhaf any execution E is inferval-linearizable wifh respecf fo O if and only if E satisfies Tq- 

Proof The sfrucfure of fhe proof is fhe following. (1) Firsf, we define Tq using O, (2) fhen, we show fhaf every 
execufion fhaf is inferval-linearizable wifh respecf fo O, safisfies Tq, and (3) finally, we prove fhaf every execution 
fhaf safisfies Tq, is inferval-linearizable wifh respecf fo O. 

Defining Tq’- We define fhe refined fask Tq = iT, O, A). Firsf, since O has only one operation, we assume 
fhaf ifs invocation and responses have fhe form inv{pj,Xj) and res{pj,yj). Lef Inv and Res be fhe sefs wifh fhe 
invocafions and responses of O. Each subsef a oi Inv confaining invocations wifh differenf processes, is a simplex 
of X. If is nol hard fo see fhaf X is a chromatic pure (n — 1)-dimensional complex. O is defined similarly: each 
subsef r of Res x 2 ^"'^ confaining responses in fhe firsf enfry wifh disfincf processes, is a simplex of O. 

We often use fhe following consfrucfion in fhe resf of fhe proof. Lef E be an execution. Recall fhaf aE and 
te are fhe simplexes (sefs) confaining all invocations and responses in E. Lef tq = ^ C ti C ... C Tm = te 
and (To = 0 C (Ti C ... C Um = cte be fhe sequences of simplexes produced by Sequences in Figure[T 8 ]on E. 
These sequences define an oufpuf simplex {(res, ai) : res ^ Ti \ Tj-i} of Tq, which will be denoted 7 ^. 

We define A as follows. Consider an inpuf simplex a & I. Suppose fhaf E is an execufion such fhaf (1) ue = or 
(2) if has no pending invocafions and (3) if is inferval-linearizable wifh respecf fo O. Nofe fhaf dim(a) = dim(TE) 
and ID{a) = ID{te). Consider fhe simplex 'Je induced by E, as defined above. Nofe fhaf dim(a) = dim{'yE) 
and ID{a) = ID{'^e)- Then, A(cj) confains ^e and all ifs faces. We define A by repeating fhis for each such a 
and E. 

Before proving fhaf T is a fask, we observe fhe following. Every dim((T)-simplex ^e C ^(< 7 ) is induced by an 
execufion E fhaf is inferval-linearizable. Eef S be an inferval-linearizafion of E. Then, for any execufion E such 
fhaf 'jF = 'JE (namely. Sequences produce fhe same sequences on E and on E), S is an inferval-linearizafion 
of X: (1) by definition, S is an interval-sequential execution of O, (2) for every process p, E\p = ,S|p, and (3) S 
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respects the real-time order of invocations and response in F because it respects that order in E and, as already 
said, they have the same sequence of simplexes and, by Claim |2]5, these sequences reflect the real-time order of 
invocations and responses. 

We argue that T is a refined task. Clearly, for each a G X, A(it) is a pure and chromatic complex of dimension 
dim(a), and for each dim(cr)-dimensional r € A(it), ID{t) = ID{a). Consider now a proper face a' of 
a. By definition, each dim(cj')-dimensional simplex 7 ®/ G A((t') corresponds to an execution E' whose set of 
invocations is a', has no pending invocations and is interval-linearizable with respect to O. Let S' be an interval- 
linearization of E' and let s' be the state O reaches after running S'. Since the operation of O is total, from the state 
s', the invocations in u \ a' can be invoked one by one until O reaches a state s in which all invocations in a have 
a matching response. Let S be the corresponding interval-sequential execution and let E be an extension of E' in 
which ( 1 ) every invocation in cj \ u' has the response in S and (2) all invocations first are appended in some order 
and then all responses are appended in some (not necessarily the same) order. Note that S' is a prefix of S and 
actually S is an interval-linearization of E. Then, A((t) contain the dim((j)-simplex induced by E. Observe 
that je' C 'Je, hence, A(it') C A(( 7 ). Finally, for every dim(cr)-simplex 7 ^ G A(( 7 ), for every vertex {idi,yi, ai) 
of 7 s, we have that at F a because 7 s is defined through an interval-linearizable execution E. Therefore, we 
conclude that Tq is a task. 

If^ is interval-linearizable, it satisfies Tq- Consider an execution E that is interval-linearizable with respect to 
O. We prove that E satisfies Tq- Since E is interval-linearizable, there is an interval-linearization S of it. Let E' 
be any prefix of E and let S' be the shortest prefix of S such that (1) it is an interval-sequential execution and (2) 
every completed invocation in E' is completed in S' (note that there might be pending invocations in E' that does 
not appear in S'). Note that S' is an interval-linearization of E'. Since interval-linearizability is non-blocking, 
Theorem[3l there is an interval-linearization S" of E' in which every invocation in E' has a response. Let E" be an 
extension of E' that contains every response in S" (all missing responses are appended at the end in some order). 
Note that aE' = cte" and te' A te"- Consider the output simplexes 7 ^/ and ^e" induced by E' and E'. Observe 
that 'je' C ^e" (because E' differs from E" in some responses at the end). By definition of Tq, 'Je" £ A((7e')> 
and hence 7 ^/ G A((T^/). This holds for every prefix E' of E, and thus E satisfies Tq- 

If E satisfies Tq, it is interval-linearizable: Consider an execution E that satisfies Tq- We prove that E 
is interval-linearizable with respect to O. Let yg be the output simplex induced by E. Since E satisfies Tq, 
'jE G A((T£:). Since A{aE) is a pure dim(cr^;)-dimensional complex, there is a dim((T)-simplex 7 ^ G A{aE) 
such that 7 e C 7 -^. Observe that cje = o'e while te F Therefore, E is an extension of E in which the 

responses in \ te are appended in some order at the end of E. Now, by construction, 7 ^ G A((T^) because 
there is an interval-sequential execution S' of O that is an interval-linearization of E. We have that S is an interval- 
linearization of E as well because, as already mentioned, E is an extension of E in which the responses in \ te 
are appended in some order at the end. 

^ Lemma [5I 
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